sycl/test-e2e/bindless_images/copies/device_to_device_copy.cpp is still marked as only supported by cuda
Also the other tests that I worked out that have failures due to issues on l0 with pitched copies are also still marked unsupported on L0: see #16977 (comment)

Alternatively one could add corresponding tests that are more unit-like for this feature, as described here: #16977 (comment)

Fundamentally, it is not clear what user use case this PR fixes. I can see that it is challenging, since the L0 spec seems to diverge from the bindless-images spec in that it always appears to use a ze_image, rather than provided interfaces that take bare pointers. And hence you have having to do some awkward massaging from one interface to the other, that is challenging to review from a correctness point of view, particularly with the aforementioned lack of tests.

The bindless-images interfaces for using bare pointer images were designed with industry standards in mind, that reflect the real use cases of image applications. It may be worthwhile to reconsider the level zero bindless-images specification if it does not allow efficient usage of target use cases of image applications.
Historically there are many examples in this project (let's use building a "house" analogy) where work on the "house" has been initiated, without the designs reflecting end-user requirements. Very skilled engineering work has been undertaken, only for the end-user (house occupants), to eventually point out that they wanted a different layout of rooms, or perhaps some fundamental architectural design, such that the whole thing must be redone. This is an experience that I think most people that undertake a large project for the first time have. It it easy to get caught up into sub-tasks, and forget the big picture of what the real end-goal is.
It is frustrating to experience, but eventually one has to learn patience to get beyond this.

Practically, the way to avoid this, is ideally to have some end-to-end tests that reflect in as minimal way as possible the requirements of the feature for end-users. I think that you will save lots of time overall, if you first consider such a test requirement, and then do whatever is required within the implementation following that, taking into account the possible need to adjust the l0 bindless-images spec if it does not meet industry requirements.

"Impatience is the cardinal sin from which all others spawn" - Franz Kafka
"Mastery is nine times patience" - Ursula Le Guin